View logon information of Domain Controller users in Windows logs

From this article, we will finally start to analyze windows logs. First, we will start from the most basic logon activities. This is also the most basic start of any log analysis, involving the analysis of user activities, always starting from the login. Wait, before this exciting time, we still want to clarify the principles of the windows login activity, and then analyze the relevant logs not too late :) From windows2000, the audit policy option involves two types of Logon: "Audit Account Logon Events" and "Audit Logon Events ". Some may not understand why there are two types of events recorded during user logon? OK. Here is a simple explanation (from the great God Randy, for details ). Before windows, for example, NT, windows only reviews logon events. In this way, if you use a domain account to log on to a workstation, the logon record of this user is not found on the domain control server (DC, it is recorded only on the accessed workstation (the premise is that the workstation has enabled logon review ). Therefore, DC does not record the authentication activities of Domain Users, making it very difficult to monitor login activities of domain users. It is necessary to collect security logs of All workstations and servers in the network. Therefore, Microsoft has added a new feature from windows, that is, "review account logon events ". However, this method is similar to the original "Audit Logon event", which is easy to confuse. Therefore, Randy thinks it is more appropriate to refer to it as "review certification events! In other words, authentication and logon activities in windows are related but different, especially when they occur on different systems! Therefore, to effectively use these two audit policies, you must understand the relevant principles and how authentication and logon occur in windows. Another obfuscation is the type of Logon account, whether it is a local account or a domain account, which affects the systems on which events are recorded. Next we will give a brief introduction to the windows Account type. Windows supports two types of accounts: domain accounts (stored in AD) and Local Accounts (stored in local SAM files ). This is also very easy. If you log on with a domain account, DC will authenticate the user. If you log on with a local account, the login workstation will authenticate the user. Therefore, you need to pay special attention to the logon activities using the local account, because attackers usually use the local account for logon attempts. Next, let's take a look at the windows logon methods. Windows supports five types of logon sessions, which respectively describe how users log on to the system. Both local and domain accounts support these five types. Each type of Logon has a corresponding logon permission. The type and method of Logon account affect the specific content and event ID of audit logs. The following table lists the types and permissions of Logon accounts. logon permissions of Logon accounts are typically interactive locally: log on to the local host using the local console and use the domain or local account to log on to the local host network: access windows resources from a host on the network access hosts from the network, such as accessing a shared folder on a host remote exchange: use Remote Desktop, terminal service, or remote help to log on to a remote host and use the local mstsc client to remotely log on to a host through Terminal Service. Batch jobs: it is used as a specified account to run a scheduled task as a batch job. When logging on to a specified scheduled task, it is specified to run the service with a specific account: to run a service with a specified account and log on as a service means to run the service with a local system account or a specific account when the specified service is running. When we attempt to log on to the network, for example, to access the shared folder of a host, the workstation will use the credential entered when the user logs on again by default. However, you can also specify a different local or domain account, for example, when ing a local disk to a shared folder. Logon VS authentication summary therefore, logon and authentication in windows are associated but different activities. In short, the logon activity occurs on the host that is finally accessed, and the authentication activity occurs on the host that stores the user account. That is, if you use a local account to log on to a host, the host will "see" authentication and logon activities at the same time. If you log on with a domain account, the DC will "see" the authentication activity, while the accessed real host will only "see" the logon activity. Therefore, "Audit Account Logon Events" are mainly used for audit policies on DC, but they are also useful on member workstations to identify attacks against local accounts. Since DC completes domain account authentication, two authentication protocols supported by windows are involved: NTLM and Kerberos. Ntlm vs Kerberos when you use a domain account to log on to Windows and later versions of the operating system, the workstation first tries to contact DC Through Kerberos protocol. (If the system does not receive a response, NTLM will be rolled back ). In addition, Widows2000 and later versions use different event IDs to record NTLM and Kerberos activities, so they are easier to differentiate. Because Kerberos provides two-way authentication between the client and the server (NTLM only supports client-to-Server Authentication ). In addition, NTLM is less secure than Kerberos, making it easier to be cracked by sniffing packets. In addition, if an external attacker attacks an account in a domain, the NTLM authentication event is usually seen, rather than Kerberos. Because they are not members of the domain or trust domain, NTLM will be used for logon attempts. The working mechanism of NTLM and Kerberos protocols is not described in detail at the moment, and because you are not very familiar with the domain, log analysis using domain account logon is skipped for the moment, start with local user authentication. In the future, you will have the opportunity to create a domain experiment environment, and then analyze the login activities using the domain account. Author shangxinmogu