8

We have a domain with about 15 servers and about 30 workstations. Servers are mostly 2008r2 and workstations are mostly Windows 7. The two DCs are 2012r2. Every few weeks, one of our admin accounts gets locked out. I'm trying to narrow down the cause and I've reached a dead end.

Here's what I have.

The event log on the PDC shows event 4776 - audit success:

Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account:  username
Source Workstation: 
Error Code: 0x0

All for the same username and recurring several times a second.

Based on the event IDs, these are NTLM logins rather than Kerberos. Though the type of authentication used is less worrisome to me than the shear quantity. This happens several times a second and repeats every couple of seconds ad infinitum, all hours day or night or weekend.

The event log also shows audit success event ID 4624 (logon) and 4634 (logoff) for this username, but as in the event above the "workstation" field is empty.

I enabled verbose netlogon logging and the netlogon.log shows 

02/28 17:11:03 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation1) Entered
02/28 17:11:03 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation1) Returns 0x0
02/28 17:11:04 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Entered
02/28 17:11:04 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server1) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server1) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server2) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server2) Returns 0x0
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation3) Entered
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation3) Returns 0x0
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Entered
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Returns 0x0
02/28 17:11:19 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation4) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation5) Entered
02/28 17:11:19 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation4) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation5) Returns 0x0
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server3) Entered
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server3) Returns 0x0
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server4) Entered
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server4) Returns 0x0

And so on and so forth. The apparent source of these logins (via XYZ) may include workstations and servers from across the network.

Clearly this looks like an automation or script. Since the logins are generally all successful, I do not believe it's an intrusion attempt. Some of the logins, however, do fail from time to time but I have not identified any pattern to the failure and they occur so infrequently that (most days) they don't lock the account out. The failure code when there is one is usually 0xc0000022 (Access Denied)

I've disabled and uninstalled our remote monitoring agent (currently Kaseya, but we're finally moving to LabTech) from one of the servers, but still saw new events originating from that server, so this rules out automation tasks. I've also checked task scheduler on a couple of servers and found nothing out of the ordinary. I've checked services to verify logon accounts and this account is not used in any services.

I ran Netstat for a good long while and saw primarily connections to the PDC from "System" and "System Idle Process". I did see occasional connections from spoolsrv and lsass and ismserv (the server I'm testing on is a Citrix XenApp server, but other "source" servers are not in the XenApp farm, and of course "source" workstations are not either). I stopped the print spooler service just to test and it had no impact on the login events.

I work at an MSP and this is our primary technician dom admin account, so it's high priority that it be working and be secure. The last idea I have left is to change the password and see what breaks, but without knowing what the account is being used for this could have potentially catastrophic consequences. However, my suspicion is that this might just be a misconfigured AD.

Has anyone experienced something like this before and been able to identify the source?

Improve this question
7
  • For anyone curious about the high number of servers, they have the XenApp servers with publicly facing SharePoint for a highly mobile workforce with BYOD. They also had a previous IT staff that went a little overboard on their infrastructure for the size of their business. Since they contracted us, we've been trying to slim them down a bit to something more appropriate to their needs.
    – Thomas
    Mar 1, 2017 at 1:31
  • Something you might try is to install Microsoft Network Monitor on one of the servers, start a capture, wait for an entry from the server to get logged to netlogon log and then look at the capture and see if you can find the conversation in Network Monitor. Network Monitor should show you the process responsible for the conversation. If that doesn't narrow it down enough you can use Network Monitor in conjunction with Process Monitor to identify the process responsible.
    – joeqwerty
    Mar 1, 2017 at 1:41
  • Microsoft Network Monitor is deprecated and replaced by Microsoft Message Analyzer. Same deal as Wireshark. I ran a packet capture and found absolutely nothing helpful. The only events that closely correlate with NetLogon events are WMI and RPC connections.
    – Thomas
    Mar 9, 2017 at 20:46
  • Right, NetMon is deprecated but it's still a good tool. If you haven't used Message Analyzer before it can be a little overwhelming. NetMon is fairly simple and intuitive. I usually use it before anything else. - As for your capture, the RPC traffic might hold some clues.
    – joeqwerty
    Mar 9, 2017 at 21:42
  • Yeah, nothing. There's one MSRPC Bind sent and Ack received to build an encrypted session followed by an NRPC packet sent and received containing a NetrLogonSamLogonEx Request and Response, the latter two being encrypted. The calling process on the source computer is LSASS, which runs the Netlogon service. There are no useful details at all in the packet data of the Bind traffic and of course the encrypted packets are useless to me.
    – Thomas
    Mar 17, 2017 at 23:15

1 Answer 1

Reset to default
1

I recommend further enabling NTLM auditing on your DC's. Using the Default Domain Controller Policy, enable the following policy settings:

Network security: Restrict NTLM: Audit Incoming Traffic = Enable auditing for all accounts Network security: Restrict NTLM: Audit NTLM authentication in this domain = Enable all Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Audit All

https://support.symantec.com/en_US/article.HOWTO79508.html

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/jj865682(v=ws.10)

Once enabled, Navigate in your event viewer to: Applications and Services Logs > Microsoft > Windows > NTLM > Operational

There will be event(s) with timestamps matching your netlogon event timestamps. This log will reveal the actual Workstation Name.

And specifically to help you identify further the source, the Secure Channel Name in this log would help narrow down the process origination.

Improve this answer
1
  • Thanks for the answer. Unfortunately this particular client is no longer a customer of ours so I'm unable to try your instructions. I've gone ahead and accepted your answer, tho, cause my own understanding of AD tells me that should give me the details I need. (Not sure why I didn't think of adjusting auditing policy, but you rock for suggesting it.)
    – Thomas
    Jan 24, 2019 at 17:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.