Logging onto an AD Server this week, we found a very worrying event in the Security Event Viewer when we saw Event ID 4776 Audit Failure every few seconds. The problem with this event is that if it does not pass on authentication, it gives you no information on where it originates.
Let’s start with why this event displays on the Domain Controller displays this message.
Local Policies
On the server, open your Local Security Policy, browse to Local Policies -> Audit Policy, and find the option, Audit Account Logon Events. Once open both options for Sucess and Failure should be Selected.
The Short Explanation:
This security setting determines whether the OS audits each time this computer validates an account’s credentials.
Scenarios
The Original scenario is we have a firewall that controls internet access based on the group each user belongs to. For the firewall to give the correct internet access at the right location the above-mentioned Policy needs to be enabled. This purely generates the logs in the Security Event Viewer. The second thing that occurred is there were some Ports opened for Specific applications to allow access from outside the network, this is where we eventually traced the authentication requests from.
While trying to set up a testing environment I could not replicate these log files on the domain controller until the Policy was enabled. The Test environment was set up with Three machines, a Newly set up Domain, a File server to authenticate to, and a Workstation to generate Authentication Errors.
File Server
The File server has a simple Share on it which only allows access to Domain Admins and Domain Users.
The IP of the server is 172.16.1.11 and the Server Name is ZADBNKSIT001VM. Because the authentication is done against it directly the Event does Display the Workstation Originating IP and Name.
Workstation
The Workstation runs a simple script that authenticates continually against the File Server with the following command:
net use \\172.16.1.11\Software /user:ad\admin RandomPassword
The details do not matter is just generate different Status codes and Failure reasons depending on the details being used for Authentication.
Workstation IP: 172.16.1.2
Workstation Name: The_FN_Workstation
As you can see the Workstation name does not display correctly based on what it actually is in the log file.
Status Codes
Below is a list of Status Codes a quick search online gave us.
| Status Code | Description |
| C0000064 | The username does not exist |
| C000006A | The username is correct but the password is wrong |
| C0000234 | The user is currently locked out |
| C0000072 | The account is currently disabled |
| C000006F | The user tried to log on outside their day-of-the-week or time-of-day restrictions |
| C0000070 | The user attempted to log on from a restricted workstation |
| C0000193 | The user tried to log on with an expired account |
| C0000071 | The user tried to log on with a stale password |
| C0000224 | The user is required to change their password at the next logon |
| C0000225 | Evidently a bug in Windows and not a risk |
Domain Controller
The Domain Controller is where the issue was originally found on. The Logs were very simple and due to the Traffic originating from outside it was not possible to resolve a hostname to IP.
To get more detail on this we need to enable additional Logging. To do this open Command Prompt (CMD) in Admin Mode on the server where you require the additional information, use the following command:
nltest /dbflag:0x2080ffff
This creates a file in %windir%\debug\ named netlogon.log
The created file logs additional logon request information like where it originates from.
When you got the information you required remember to turn off the logging with the command:
nltest /dbflag:0x0