Windows servers can run into situations where it may be mighty handy to get a better understanding of what computers are connecting to a server for services. What does “connecting to a server for services” mean?
Consider the Exchange server scenario. For this scenario let’s postulate that the client is a Windows Outlook client connecting to get email. To do that action the client does an RPC connection to the Exchange server. This RPC session is authenticated (hopefully using Kerberos though there are scenarios where NTLM is used) and does a Network Logon.
A network logon is simply a non-interactive logon to a computer from a remote client. Logon types are classified and tracked as Interactive, Network, RemoteInteractive and a few others. More information on auditing and logon type descriptions can be found in this TechNet article.
Auditing can give you a 1:1 idea of which users a logging onto a server and from where, but collating that into a more holistic view is more difficult using in box tools. If you need to track specific network logons over time-and if you have a requirement to keep forensic data regarding what client users and computers are connecting to a server then auditing is the way to go.
The network logon can be tracked via user logon auditing-if the server has that enabled-but it may also be tracked by SamLogon entries in a NetLogon debug log. SamLogon entries are roughly analogous to a network logon.
More to the point, there are plenty of times where you simply need to answer questions like “what domains to clients belong to who are connecting to the server?” or “are any of the clients submitting malformed NTLM authentication where the domain portion of the domain\user is missing?” or “did any of the clients connecting get timeout errors?”.
Worse still is performance bottlenecks where a server is having to perform so many NTLM password validations or Kerberos PAC validations that some of them time out and give errors. Errors like credential prompts or simple “spinning donut” waits.
Errors like that are the result of the dreaded MaxConcurrentApi issue where too many NTLM or Kerberos PAC validations are coming than can be serviced before timing out. More info on MaxConcurrentApi issues can be found in this TechNet wiki article.
If you need to run a diagnostic in your environment to see if MaxConcurrentApi issues are happing then you can run the Microsoft CSS MaxConcurrentApi Diagnostic from the Self Help Diagnostic Center. More info on the diagnostic is available in this KB article:
[SDP 3][52a5f43b-2db9-40b7-88ae-fd9842cca85f] MaxConcurrentApi Diagnostic
No Microsoft support case needed to run it you simply need a Live account. Alternatively you can run the MaxConcurrentApi script from the TechNet Script center (available for download from this link).
Now, let’s get to the point of this article. A new PowerShell script is available which can give you the statistics about what SamLogon events are occurring to a server. It is intended to help give you supplemental information so that you can know what is happening to your servers in aggregate. The script parses NetLogon debug log files to give that info. Netlogon debug logging can be enabled using the KB article:
Enabling Debug Logging for the Net Logon Service
The PowerShell script can be download from the TechNet Script Center at this link.
An example of the switches to run the script:PS C:\Scripts> .\MaxConcurrentApiNetlogonParser.ps1 -NetlogonFilePath $Log -DomStats $true -AuthFailureDetails $true
More information about using the script:
Here’s an example:
Netlogon Analysis of SamLogon Entries
Analysis will show a percentage breakdown of the domains from which users are logging onto the server.
The logon sessions are Network logon sessions.
NOTE: Computers may show up as domains if the auth is from non-domain joined clients or apps which submit authn improperly.
Analysis of Netlogon Log File C:\windows\debug\netlogon.log
Log start time 04/10 06:55:31
Log end time 04/10 07:38:39
Total Samlogon (network logon) entries were: 58482
Domain CHILD.TREYRESEARCH.COM : 14 %
Domain (null) : 1 %
Domain TREYRESEARCH.COM : 30 %
Domain CHILD.CONTOSO.COM : 30 %
Domain CONTOSO.COM : 2 %
Domain TAILSPIN : 2 %
Domain TAILSPINTOYS.COM : 13 %
Domain RESEARCH.TAILSPINTOYS.COM : 1 %
Domain CONTOSO : 4 %
Analysis of Netlogon Log File C:\windows\debug\netlogon.logLog start time 04/10 06:55:31Log end time 04/10 07:38:39*******************************************Summary of User Failures by Domain (estimated):Note: Computers names may appear as domains if the authentication is improperly submitted by the client.
NTLM user auth failures for domain:REGIONALNTLM user auth failures count:6
NTLM user auth failures for domain:CHILD.TREYRESEARCH.COMNTLM user auth failures count:4044
NTLM user auth failures for domain:(null)NTLM user auth failures count:5
NTLM user auth failures for domain:TREYRESEARCH.COM NTLM user auth failures count:164
NTLM user auth failures for domain:RESEARCH.TAILSPINTOYS.COMNTLM user auth failures count:7942
NTLM user auth failures for domain: CONTOSO NTLM user auth failures count:7932
NTLM user auth failures from Problematic NTLM AuthCount of NTLM user timeouts from (null)\ domain:5
User names of users whose computers or devices submitted problematic NTLM auth (without a domain name)Null user is shakalaNull user is email@example.com Null user is firstname.lastname@example.org Null user is eeriendNull user is email@example.com
Computers or devices from where users submitted problematic NTLM auth (without a domain name).Null computer is shakalapc-1Null computer is CCFNG-WIN7-2Null computer is RSRCH2008Null computer is EMEA-WS66342Null computer is JIMMYSTABLET
If you are in a situation where you are ramping up the load on a new server or server farm, if you suspect you are seeing load based issues related to authentication on a server or if you simply want to know more about the clients connecting to a server in a holistic way then this script can help you out.