10

Why is a demoted domain controller still authenticating users?

Whenever users log onto workstations with domain accounts, this demoted DC authenticates them. Its security log shows their logons, logoffs, and special logons. Our new DCs' security logs show some machine logons and logoffs, but nothing to do with domain users.

Background

  1. server1 (Windows Server 2008): Recently demoted DC, file server
  2. server3 (Windows Server 2008 R2): New DC
  3. server4 (Windows Server 2008 R2): New DC

Logs

Security Log Events: http://imgur.com/a/6cklL.

Two sample events from server1:

Audit Success,3/31/2014 11:06:14 AM,Microsoft-Windows-Security-Auditing,4624,Logon,"An account was successfully logged on.

Subject:
    Security ID:        NULL SID
    Account Name:       -
    Account Domain:     -
    Logon ID:       0x0

Logon Type:         3

New Logon:
    Security ID:        MYDOMAIN\auser
    Account Name:       auser
    Account Domain:     MYDOMAIN
    Logon ID:       0x8b792ce
    Logon GUID:     {54063226-E9B7-D357-AD58-546793C9CA59}

Process Information:
    Process ID:     0x0
    Process Name:       -

Network Information:
    Workstation Name:   
    Source Network Address: 192.168.20.143
    Source Port:        52834

Detailed Authentication Information:
    Logon Process:      Kerberos
    Authentication Package: Kerberos
    Transited Services: -
    Package Name (NTLM only):   -
    Key Length:     0

[ ... ]

Audit Success,3/31/2014 11:06:06 AM,Microsoft-Windows-Security-Auditing,4624,Logon,"An account was successfully logged on.

Subject:
    Security ID:        NULL SID
    Account Name:       -
    Account Domain:     -
    Logon ID:       0x0

Logon Type:         3

New Logon:
    Security ID:        MYDOMAIN\anotheruser
    Account Name:       anotheruser
    Account Domain:     MYDOMAIN
    Logon ID:       0x8b74ea5
    Logon GUID:     {7E74986A-7A4D-B6E0-5D6F-D8CF78E8C718}

Process Information:
    Process ID:     0x0
    Process Name:       -

Network Information:
    Workstation Name:   
    Source Network Address: 192.168.20.203
    Source Port:        53027

Detailed Authentication Information:
    Logon Process:      Kerberos
    Authentication Package: Kerberos
    Transited Services: -
    Package Name (NTLM only):   -
    Key Length:     0

Sample Audit Policy Change event from server3 (there are also Audit Policy Change events in the log with changes marked "Success Added"):

System audit policy was changed.

Subject:
    Security ID:        SYSTEM
    Account Name:       SERVER3$
    Account Domain:     MYDOMAIN
    Logon ID:       0x3e7

Audit Policy Change:
    Category:       Account Logon
    Subcategory:        Kerberos Authentication Service
    Subcategory GUID:   {0cce9242-69ae-11d9-bed3-505054503030}
    Changes:        Success removed

Attempted Solutions

  1. Fixing DNS entries. dcdiag /test:dns at first returned errors after server1 was demoted. There were outdated name server entries in our forward lookup zones, for example. I ended up opening DNS Manager and removing the problem entries manually, also ensuring that LDAP and Kerberos entries pointed to the new servers. For instance, __ldap.Default-First-Site.__sites.dc.__msdcs.mydomain.local_ points to server3.mydomain.local.
  2. Verifying DNS entries with nslookup. nslookup -type=srv _kerberos._udp.mydomain.local returns entries for server3 and server4—nothing about server1.
  3. Cleaning up metadata. After using ntdsutil to clean up metadata as described in this TechNet article, the ntdsutil command list servers in site returns only two entries, which both look OK:
    1. 0 - CN=SERVER4,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=mydomain,DC=local
    2. 1 - CN=SERVER3,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=mydomain,DC=local
  4. Deleting server1 from Active Directory Sites and Services. After demoting server1, I noticed it remained in Active Directory Sites and Services, although it was no longer listed as a global catalog. I deleted it according to the instructions in this Microsoft KB article.
  5. Transferring operations master roles to server3. Operations master roles are a bit beyond my ken, but I used ntdsutil to transfer them all to server3 this morning. There were no errors, but reboots and tests showed that server1 was still doing all the authentication.
  6. Reregistering with DNS and restarting netlogon. A forum post suggested running ipconfig /registerdns and net stop netlogon && net start netlogon on the new servers to resolve a related issue. It didn't seem to help.
  7. Ensuring that the winning GPO on the new domain controllers enables auditing for logon and account logon events.

Other Leads

  • The same problem is described in this series of forum posts. There's no resolution.
  • It's also described in this question on Experts Exchange. The comment marked as an answer reads, "If the its [sic] not a DC anymore, then there is no way it can be processing any authentication requests." That would be my reaction, but running dcdiag on server1 confirms that server1 doesn't consider itself a DC. Yet it's still the only server authenticating everybody.

What's going on here?

2 Answers 2

12

It's a file server - are users connecting to it to get access to files? That's likely what you're seeing. Those would show up in the security logs.

Post some log entries (in their entirety - text dump or screenshot) from server1 that is showing the behavior you're concerned about.

/Edit - Thanks for confirming. Logon Type 3 is "Network." Most often seen when accessing shared files or printers on the computer that logged the event.

12
  • Thanks—I uploaded screenshots of the servers' security logs to imgur in an edit. Apparently I don't have enough reputation to upload images, so the link is spelled out in text. Mar 31, 2014 at 14:47
  • The odd thing to me is that only server1 logs anything about logons and logoffs. I agree that those should show up on a file server, but don't DCs log them when users are authenticated? Mar 31, 2014 at 14:48
  • 1
    Log entries in their entirety, please. Show the actual log event with all text, not a list of all the log entries, from server1.
    – mfinni
    Mar 31, 2014 at 14:58
  • 3
    Quick comment for any readers with the problem of new DCs not logging audit events: It turns out that corrupt audit.csv files were overriding the Group Policy audit settings as described here. After deleting the CSV files and running auditpol /clear and gpupdate /force on the new DCs, all is working. I owe @mfinni for pointing me in the direction of GPO audit settings when I was on all kinds of wild goose chases in troubleshooting! Mar 31, 2014 at 20:06
  • 1
    Sounds good - glad you got that down. You'll definitely want to spend some time reading up on the care and feeding of domain controllers, best practices, etc. MS has a lot of good articles and training available, too.
    – mfinni
    Mar 31, 2014 at 20:27
2

A demoted DC will in no way continue to authenticate domain logons. What you are seeing is local logon events. When you log onto a member server w/ domain credential, you will see logon events locally, plus corresponding credential validation events on DC.

When you log onto member server with local credential, you still see logon events locally, but won't see any credential validation events on DC.

1
  • 1
    Exactly right—it turned out that the demoted DC was logging authentication for file shares only. What confused me was that the new DCs weren't logging authentication events at all. The problem ended up being that the audit.csv files on the new domain controllers were corrupt, but following the instructions on deleting those files in these TechNet posts resolved that. Apr 2, 2014 at 19:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .