Windows security event 612

All rights reserved. Disclaimer: We do our best to provide quality information and expert commentary but use all information at your own risk. For complaints, please contact abuse ultimatewindowssecurity. Terms of Use Privacy Return Policy. Operating Systems. Windows Server Windows and XP.

Policy Change. Corresponding events in Windows and Vista. User name:. About Newsletter Contact. Website Support Live Demo Forums. Knowledge Base.

Active Directory Auditing Tool. Process Tracking » Policy Change Event: Enter your email id. The domain controller is simply performing the authentication check. Therefore the old "audit logon events" audit policy doesn't do you much good for tracking domain user logon activity or failed logon attempts. You'd have to enable "audit logon events" on each workstation and server on your network and then monitor those logs and you still wouldn't see failed logon attempts by attackers using their own workstation.

Thus, the need for the new audit policy introduced with Windows - "audit account logon events". When you enable this policy on Windows or domain controller this policy records all domain account authentication that occurs on that domain controller in that domain controller's security log. When you analyze the combined "Account Logon" activity of all your domain controllers you now how a complete picture of the logon activity of all domain accounts in your domain regardless of where the logon attempts are initiated from - computers of the local or trusted domain or even unknown computers completely outside your AD forest and external trusted domains.

When a Windows or later computer needs to find out if a domain account is authentic the computer first tries to contact the DC via Kerberos. If it doesn't receive a reply it falls back to NTLM. In an AD forest comprising computers running Windows and later all authentication between workstations and servers should be Kerberos. Windows and later domain controllers log different event IDs for Kerberos and NTLM authentication activity so it's easy to distinguish them.

In an AD forest of Windows or later computers, any NTLM authentication events you see on domain controllers can only have a few explanations. Second, if your domain trusts another domain outside your forest defined in Active Directory Domains and Trusts you'll see NTLM events on you domain controllers since Kerberos doesn't work for external trust relationships.

Note: Windows Server supports a new type of trust call cross forest trusts. A cross forest trust is a transitive, 2-way trust between 2 Windows Server domains. The third explanation for NTLM events on your domain controller's security log are rogue computers. Contrary to popular misconception, Windows does not prevent a user at a computer from an un-trusted domain or stand-alone computer Windows computer that doesn't belong to any domain from connecting to a server in your domain using a domain account.

To prove this just map a drive to a computer in an untrusting domain using the "net use" command. About the only other explanation for NTLM events on your domain controller security logs is more mundane - you just have some pre Win2k computers somewhere in your local domain or in the overall forest. The bottom line is that if an outsider is attacking accounts in your domain you will most likely see them as NTLM authentication errors - not Kerberos.